perm filename X3J13.MSG[COM,LSP]7 blob
sn#845863 filedate 1987-09-16 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂06-Feb-87 2207 RPG next x3j13 agenda
∂06-Feb-87 1753 FAHLMAN@C.CS.CMU.EDU next x3j13 agenda
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Feb 87 17:49:10 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 6 Feb 87 20:48:38-EST
Date: Fri, 6 Feb 1987 20:48 EST
Message-ID: <FAHLMAN.12277009706.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@ADA20.ISI.EDU
Cc: bobrow.pa@XEROX.COM, gls@ZARATHUSTRA.THINK.COM, rpg@SAIL.STANFORD.EDU,
scherlis@VAX.DARPA.MIL, squires@VAX.DARPA.MIL,
willc%tekchips@RELAY.CS.NET
Subject: next x3j13 agenda
In-reply-to: Msg of 3 Feb 1987 17:34-EST from MATHIS at ADA20.ISI.EDU
That leaves Wed morning for the "cleanup" committee. That may be
right for an initial session of that type, but we cann't expect
much in the way of results.
The compiler committee may actually have more to present than the
cleanup committee. Rob Maclachlan has produced an excellent proposal
that looks to me like it might fix up almost all the outstanding
compilation issues at one swoop. Whether the rest of the compiler
committee will want to put this forward as a proposal, I can't say.
Unfortunately, Rob won't be at this meeting (CMU has no budget for such
travel), but perhaps one of the other compiler committee people will
want to present Rob's proposal.
I think that the cleanup committee is going to have to be reorganized so
that some work gets done. Most of the original members have been
inactive, and some have been downright incommunicado. I think we're
going to have to oust the inactive members and try to add some new ones
with more time and energy for this task. I think this will need to be
discussed by mail BEFORE the meeting, rather than trying to solve the
problem in the middle of the conference. If we just ask for volunteers,
we'll get all the wrong people and things will be even worse than now.
I think that the right move might be to invite some specific people to
join the committee and help out: Rob, Skef Wholey, Eric Benson...people
who might be able to grab a few issues and run with them.
I don't know if there will be anything to report on errors, presentation
of the standard, windows, or the other issues that had committees set up
for them.
Any chance that a more or less final object proposal will be ready for
circulation before the meeting?
I don't see any point in wasting any more time on Lisp1/Lisp2 until
someone has a coherent Macro proposal to present and some better ideas
on how to automate the transition. No sense plowing the same technical
ground and stating the same opinions over and over again, unless the
plan is to bring this to a final vote and be done with it once and for
all.
-- Scott
∂09-Feb-87 1033 RPG Re: next x3j13 agenda
∂09-Feb-87 0851 Bobrow.pa@Xerox.COM Re: next x3j13 agenda
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Feb 87 08:51:12 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 FEB 87 08:44:44 PST
Date: 9 Feb 87 08:44 PST
Sender: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: next x3j13 agenda
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Fri,
6 Feb 87 20:48 EST
To: Fahlman@C.CS.CMU.EDU
cc: MATHIS@ADA20.ISI.EDU, bobrow.pa@Xerox.COM,
gls@ZARATHUSTRA.THINK.COM, rpg@SAIL.STANFORD.EDU,
scherlis@VAX.DARPA.MIL, squires@VAX.DARPA.MIL,
willc%tekchips@RELAY.CS.NET
Message-ID: <870209-084444-5562@Xerox>
Any chance that a more or less final object proposal will be
ready for circulation before the meeting?
We expect to circualte a document to the committee so that it can be
presented. As to what "final" means, we have mostly agreed on most of
the contents, but what happens when the committee sees it.
danny
∂19-Feb-87 1216 RPG Re: Questions
∂19-Feb-87 1113 MATHIS@ADA20.ISI.EDU Re: Questions
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Feb 87 11:13:36 PST
Date: 19 Feb 1987 10:15-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: Questions
From: MATHIS@ADA20.ISI.EDU
To: RPG@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]19-Feb-87 10:15:25.MATHIS>
In-Reply-To: The message of 18 Feb 87 0948 PST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Dick,
I will try to retransmit my prior message on new addresses to
rmaiii at sail etc.
yes slater is the smoker. try slater@a.isi.edu.
my tendency has been to put people on the list and then check
them later. I sent letters to about a dozen people on the
physical list and about six of them dropped off. After the Palo
Alto meeting and the X3 bills, I was planning to question some of
the people on both the electronic and physical lists.
I think of the meetings as partially open. Additional people
from the same companies as members are welcome as are potential
new members; but not just anybody. Speaking and participating
might be restticted.
Bob
∂20-Feb-87 0931 RPG Re: Address
∂20-Feb-87 0653 MATHIS@ADA20.ISI.EDU Re: Address
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 Feb 87 06:52:52 PST
Date: 20 Feb 1987 06:52-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: Address
From: MATHIS@ADA20.ISI.EDU
To: RPG@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU]20-Feb-87 06:52:52.MATHIS>
In-Reply-To: The message of 19 Feb 87 1230 PST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Dick, you had about three items:
1. in an attemp to be efficient I cleaned-up my old messages when
I put that address list together for you, so I don't know who
RMAIII is either. Even though I wish I could answer the
question, this is the first time I have deleted a message that I
later wanted back. That situation occurs so infrequently, I am
sure I am not deleting enough.
2. about all those names from Symbolics and Xerox. I am waiting
to see how many they are willing to pay for. It is also early.
Moon hasn't come to a meeting yet, but is very active; Masinter
wasn't on the original Xerox list and now he is also very active.
3. About the ISO meeting. Since the French will have the
convenorship, it is natural for them to want to host the first
meeting in France. The European countries seem to be much more
concerned about invitations to meet in particular countries and
so the French would not invite themselves to Italy. We can
however point out in our ballot that it would be nice to have the
meeting in Italy and the Italian standards body hopefully would
respond by inviting us. Another solution is to hold the meeting
in France (Paris or Nice for example) at a time that could fit in
nicely with IJCAI in August. The reason for this June suggestion
was some other conference they wanted to attach to. I really
don't have any other information on that. It may be possible
that we would like to attend that conference anyway. I don't
know. In any case We can suggest the August meeting time. I
didn't know anything about this funding business.
-- Bob
∂04-Mar-87 1413 RPG PART 2 of 2
∂04-Mar-87 0919 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET PART 2 of 2
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 4 Mar 87 09:18:45 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa27273; 4 Mar 87 11:00 EST
Received: from utokyo-relay by RELAY.CS.NET id ad23660; 4 Mar 87 10:52 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA16027; Thu, 5 Mar 87 07:23:08+0900
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
id AA29804; Thu, 5 Mar 87 00:22:28+0900
Date: Thu, 5 Mar 87 00:22:28+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8703041522.AA29804@tansei.u-tokyo.junet>
To: mathis@ADA20.ISI.EDU, rpg@SAIL.STANFORD.EDU
Subject: PART 2 of 2
---- PART 2 Activities of Selected Working Groups
A Survey on needs for Lisp and AI applications in Japan
Ryu Katayama, Sanyo Electric Co.,Ltd.
1-18-13 Hashiridani Hirakata, Japan
Jeida Lisp Committee made a survey on Lisp and AI applica-
tions from Nov. 1985 to Feb. 1986 to clarify the current needs
and trends of AI languages (including Lisp) and AI applications
in Japan [1]. The contents of questionnaire are (1) company out-
line, (2) interests and development policy on AI systems, (3)
needs for AI languages and its applications, (4) needs for Lisp,
(5) needs for Common Lisp, and (6) Common Lisp subsetting. 350
questionnaires were sent to researchers and engineers engaged in
knowledge information processing, and among 135 replies, 56 are
from those who belong to private companies, 37 from universities,
and 42 from public research institutes and others.
Concerning interests on AI systems such as expert system
(ES), image recognition, voice recognition, machine translation,
CAI system, and intelligent robot, ES is most interested in
(91.1%), followed by machine translation (57.0%), image recogni-
tion (52.6%). Also over 10 % answers indicate that those three AI
systems are now commercially developed at their own organiza-
tions.
With respect to (3), needs for AI languages are surveyed in-
cluding hardware environments. Most widely used machine is VAX-11
family (72), followed by SUN (28), Xerox-1100 series (27), Sym-
bolics (22), FACOM M series (17), ACOS series (17), HITAC M
series (16), USTATION (15), DEC 20XX family (15).
Commonly used AI languages are illustrated in Fig.1. Widely
used Lisp languages are Franz Lisp (60), VAX Lisp (40), Inter-
lisp/ Interlisp-D(33), UtiLisp (33), Zetalisp (18), Kyoto Common
Lisp (17), while popular Prolog languages are C-Prolog (46),
Prolog-KABA (44), DEC-10 Prolog (23), micro-Prolog (19), Quintus
Prolog (17), Prolog/KR (17), and so on. Familiarly used object
oriented languages are smalltalk-80 (38), Flavors (19), Loops
(7), Objective-C (8). Among other conventional languages, C (89
answers), FORTRAN (51), PASCAL (49), BASIC (30) are also used.
Major objectives for those AI languages are for development
of ES (29.6%), natural language processing (including machine
translation) (17.8%), intelligent man machine interface (17.8%),
image recognition/understanding (10.4%).
On the development of ES, 62.8% organizations are developing
ES by their own, and among them 46.8% are also developing ES
development tool (shell), while 32.3% utilize commercially avail-
able shells. Most commonly used language for developing shell is
Lisp (55 answers), followd by Prolog (26), C (19). Widely used
shells are OPS5 (18), KEE (8), ZEUS (7), ART (5), BRAINS (4).
Concerning needs or complaints for Lisp, many users tend to
point out slow execution speed (32), poor graphics (28), inabili-
ty to handle Japanese characters (26), lack of object oriented
facilities (18), large size of required memory (16), inefficient
programming tools such as editor or debugger (16).
With respect to Common Lisp (CL), 82.7% are interested in CL
, and 66 users already introduced CL, 21 are planning to intro-
ducing CL.
Concerning language specifications of CL, there are comments
that appreciates its compiler oriented design such as lexical
scope or function closure (20.3%), sufficient data types (8.6%),
while point out the large memory use (21.4%), needs for object
oriented facilities (18.7%), requests for supporting Japanese
characters (16.0%), etc.
On the needs for subsetting CL, 60.2% answers indicate that
some suitable organization or committee should deal with the
standardization of CL subsets.
Based upon the survey, needs for standardization of CL sub-
sets, object oriented facilities, embedding Japanese characters
in CL are considered to be made clear in Japan.
number of users
0 10 20 30 40 50 60
------------------------------------
| | | | | | |
Franz Lisp |****************************** (60)
C-Prolog |************************ (46)
Prolog-KABA |********************** (44)
VAX Lisp |******************** (40)
smalltalk-80 |******************* (38)
Interlisp,Interlisp-D |***************** (33)
UtiLisp |***************** (33)
DEC-10 Prolog |************ (23)
micro-Prolog |********** (19)
Flavors |********** (19)
Zetalisp |********* (18)
Kyoto Common Lisp |********* (17)
Quintus Prolog |********* (17)
Prolog/KR |********* (17)
Maclisp |******** (16)
muLisp |******* (14)
PSL (Protable Standard Lisp) |******* (13)
K-Prolog |****** (12)
Loops |**** (7)
MProlog |**** (7)
Objective-C |*** (5)
Fig. 1 Commonly used AI Programming Languages in Japan '85
Acknowledgements
The author would like to thank Jeida Lisp committee members who
made great efforts to accompolish this survey, especially Satoshi
Uchida and his colleagues of Aoyama Gakuin University for their primary
analysis of the collected data.
================================================================
Activities of Subset Working Group
Katsuhiko Yuura
Central Research Laboratory, Hitachi,Ltd.
1-280, Higashi-koigakubo, Kokubunji-shi, Tokyo 185, Japan
1. Background and Purpose
Most Japanese Lisp users on personal computers(pc) do not
use all functions of the full set of Common Lisp so that good
performance is a constant concern. Although some subset imple-
mentations for pc have been developed, they not surprisingly have
different specifications. To set up an international Lisp stan-
dard for pc, the authors would like to propose a subset, which
does not include seldom used functions and those that make a sys-
tem inefficient.
2. Discussions and Proposal Activities
Discussions for the subset started in December 1985, and the
authors decided on four steps for the completetion of Common
Lisp/Core. The first step was the review of Ida's personal pro-
posal for a subset (IPSJ WGSYM 34-4), and the second step was the
examination of the necessities for each function and the diffi-
culties in implementing them. In the third step the basic issues
of Common Lisp/Core were decided, and in the fourth step the
functions were selected by the vote of WG members.
An open meeting on Common Lisp/Core was held in Tokyo on
July 8, 1986, in which sixty researchers and users came together.
From the implementer's point of view, it was felt that the scale
of Common Lisp/Core was not so much smaller than that of the full
set. From the user's point of view, it was hoped that more func-
tions were selected from packages, streams and declarations.
Common Lisp/Core was proposed at the Lisp standardization
meeting on August 5, 1986 during Lisp and Functional Programming
Conference. Common Lisp/Core is regarded as the middle position
of three levels, which are theoretical basis, kernel and practi-
cal use, of the Lisp language definition.
3. Basic Issues of Common Lisp/Core
Common Lisp/Core preserves the arms and legs of Common Lisp,
because it is important to be able to transfer programs in the
subset to those in the full set easily, as well as to enable sub-
set users to grow into full set users naturally. The following
"arms and legs" features were selected in the third discussion
step: scope and extent rules including lexical closure features,
keyword parameters, the principles of type hierarchy and generic
functions, and some useful and characteristic data types (bignum,
ratio, structure and readtable). Some package features are very
useful, and other parts are not so useful and make a system
heavy. But the useful part can not be cut out of the whole pack-
age features with keeping Common Lisp/Core language consistent.
On the other hand, Common Lisp is characterized by rich
functions, so that the aim for the number of functions in Common
Lisp/Core is about a half of the full set, which is over that of
Utilisp (developed at University of Tokyo in 1981, one of the
most famous Lisps' in Japan) or Franzlisp. The functions which
do not correspond to the "arms and legs" features were selected
in the fourth discussion step, giving higher priority to func-
tions having high necessity than to functions that can be imple-
mented easily.
Common Lisp/Core includes 356 functions and 20 variables and
constants, wheras Common Lisp includes 622 functions and 101
variables and constants. Major deleted items are most system
parameter constants, complex numbers, most package features, lo-
cal functions, adjustable arrays, hashtables and pathnames.
Subset WG members :
Hideki Kato (Fujitsu Laboratories Ltd.)
Yukiko Hashimoto (NEC Corp.)
Kazusaku Kawagome (SORD Computer Corp.)
Susumu Kawai (Nihon Digital Equipment Corp.)
Shigeaki Harada (Sharp Corp.)
Yoichi Yamamura (Nippon UNIVAC Kaisha Ltd.)
Nobuyuki Saji (NEC Corp.)
Masayuki Ida (Aoyama Gakuin Univ.)
====================================================================
Recent Activities of Object Oriented Programming Working Group
Toru Ishida
NTT Electrical Communication Laboratories
1-2356 Take, Yokosuka-shi, 238-03, Japan
The working group for Object Oriented Programming (OOWG) was organized
in April 1985 as the first working group of the JEIDA Common Lisp
Committee. Although there were more urgent problems for the Japanese
Lisp Society, such as subsetting and handling Japanese characters, we
started the OOWG so early because:
- The Object Oriented Programming paradigm was the center of attention
in Japanese academic society at that time. However, notion and its
effectiveness were not well understood by industrial society.
- Standardization of new programming paradigms requires a lot of
experience. Thus, we thought discussion should begin as soon as
possible.
In 1985, six companies joined the OOWG. Our first job was to arouse
positive public opinion about the movement toward standardization of
Lisp Object Oriented Programming. The members reviewed and summarized
on-going discussions at the Common Lisp Committee of the United
States, and reported on the major problems in standardization to the
JEIDA Lisp Workshop[1] and the IPSJ (Information Processing Society of
Japan) Special Interest Group of Symbolic Processing. The reports
include analysis of the three standardization proposals from HP, Xerox
and LMI.
Since 1986, fourteen companies have been involved in the OOWG. More
people have participated in the discussions and contacted people
outside of the working group. Several members of the OOWG attended
the Lisp Standardization Meeting in Boston in August. In addition, an
extended JEIDA meeting with Gregor Kczales, a co-author of
CommonLoops[2], was held in October. Various other matters have also
been discussed at meetings and through mail networks.
Discussions have also been expanded to cover wider problems. Language
specification issues have been clarified through the use of the
Portable CommonLoops provided by Xerox Corporation. From the end of
1986, discussions have involved Object Oriented Programming
Environments and applications: AI tools, window systems, etc.
As a summary of our activities in the last two years, the OOWG has
contributed to the understanding of Lisp Object Oriented Programming
in Japanese industry. In the next stage, we hope to contribute to
international standardization of Lisp Object Oriented Programming.
[1] Report on Microcomputer - Common Lisp - , Jeida, 61-A-235[2],1986
(in Japanese)
[2] D. G. Bobrow et al: CommonLoops: Merging Common Lisp and
Object-Oriented Programming, Proc. of OOPSLA '86, ACM, 1986.
Contributors:
Nobuyuki Saji (NEC Corp.)
Kiyoki Ohkubo (Panafacom Ltd.)
Taiji Nishida (Fuji Zerox Co., Ltd.)
Haruyuki Kawabe (Nippon UNIVAC Kaisha Ltd.)
Tadashi Maruyama (FUJIFACOM Corp.)
Yasutaka Tominaga (Fuji Electric Corporate Research and Development Ltd.)
Hiroshi Nakajima (OMRON TATEISI ELECTRONICS Co.)
Makoto Yokoo (Nippon Telegraph and Telephone Corp.)
Satoshi Uchida (Aoyama Gakuin Univ.)
Masayuki Ida (Aoyama Gakuin Univ.)
=============================================================
Kanji WG --- Embedding Japanese Characters in Common Lisp
MOTOYOSHI, F.
Electrotechnical Laboratory,
1-1-4 Umezono, Sakura-mura, Niihari-gun, Ibaraki,
305 JAPAN
We have discussed the way to embed Japanese characters
in Common Lisp for a year. We first decided on the policy to
be followed in the whole discussions:
a Japanese character should be treated as a character of
Common Lisp.
All members of the working group agreed this policy and many
users prefer it to others.
Then we drew up guidelines to be respected within the
limits of above policy. The are
1) a program which is written without regard to Japanese
characters should run as expected when it is given data
which include Japanese characters,
2) any multi-byte character set other than Japanese
characters can be implemented in the same manner,
3) a program which does not deal with Japanese characters
should run without so much loss of efficiency for speed
and memory.
According to above principles, we have made a proposal
to embed Japanese characters in Common Lisp as described in
the following. The basic idea is very simple and is that
let the value of 'char-code-limit' be large enough for
the system to include all Japanese characters.
This means that one can even define a read macro to any
Japanese character.
By taking that way, we need only one change to CLtL,
which is concerning to character printing width. The point
is that the set of fixed-pitch characters for font 0 is
limited to graphic standard characters. Instead, we
introduce a function 'write-width' for getting the print
width.
No problem occurs when a system has a uniform internal
structure for strings, however, some system may have two or
more types of strings internally for memory efficiency.
There may be some loss of efficiency for users who use only
standard characters in such a system.
A new type of string is introduced in such cases and is
used mainly in declarations. The name is
'internal-thin-string', which is a vector of special
characters distinguished from others by a predicate
'internal-thin-char-p'. This does not mean that 'internal
thin character' should be a proper subset of 'string
character'. They may represent a same character set and this
case is equivalent to the above one for uniform structure of
string.
We have described the common topic to any multi-byte
characters so far. We also discussed the problem specific to
Japanese, where our main concerns are related to the meaning
of each Japanese character. The major problem is that of
characters whose print forms are similar to those of standard
characters. We reached to the agreement that any system
should have at least one mode where any characters other than
standard characters have not special meanings. Althogh
functions to define classes of Japanese characters were also
determined, they are not described in this paper.
Contributed by
IKEO, J. (Fuji Xerox Co., Ltd.)
KIMURA, K. (Toshiba Corp.)
MURAYAMA, K. (Nippon Univac Kaisha, Ltd.)
NAKAMURA, S. (Fujitsu, Ltd.)
OKA, M. (Japan Radio Co., Ltd.)
SAKAIBARA, K. (Hitachi Co., Ltd.)
SHIOTA, E. (Nihon Symbolics Corp.)
SUGIMURA, T. (Nippon Telegraph and Telephone Corp.)
∂04-Mar-87 1416 RPG PART 1 of my report
∂04-Mar-87 0945 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET PART 1 of my report
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 4 Mar 87 09:45:05 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac27173; 4 Mar 87 10:50 EST
Received: from utokyo-relay by RELAY.CS.NET id ab23660; 4 Mar 87 10:46 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA16012; Thu, 5 Mar 87 07:22:33+0900
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
id AA29798; Thu, 5 Mar 87 00:21:53+0900
Date: Thu, 5 Mar 87 00:21:53+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8703041521.AA29798@tansei.u-tokyo.junet>
To: mathis@ADA20.ISI.EDU, rpg%su-ai.arpa@RELAY.CS.NET
Subject: PART 1 of my report
A progress report on the Common Lisp related activities in Japan
Compiled by Masayuki Ida
This report is composed of two parts.
One is a survey of the recent activities related to Common
Lisp and Lisp standardization efforts in japan by Masayuki Ida,
who chairs the Jeida Common Lisp committee, and the JIS Lisp WG
both.
The other is the reports of the sub working groups under the
Jeida Common Lisp committee by each chair.
Since JIS Lisp WG has only 7 months history and still in the
'first' phase to design a draft, this paper is mainly stressed on
the activities of Jeida Common Lisp committee.
The contents of this report contains lots of contributions
of many persons, the authors express their thanks to all the con-
tributors. This report is not the official ones, though each au-
thors is (was) responsible person for each group.
----- PART 1 Summary
Masayuki Ida
Aoyama Gakuin University
1 Morinosato-aoyama, Atsugi, Kanagawa, Japan 243-01
ida%u-tokyo.junet@utokyo-relay.csnet
ida@utokyo-relay.csnet
1. before the dawn --- 1984 ----
The year 1984 is the year CLtL was published. In USA, a conver-
gence of the E-mail discussions gave CLtL, while in japan, the
possibility to form a committee to investigate the current move-
ment of Lisps had been discussed. As one of the candidates, The
author proposed to form a Common Lisp related committee for Jei-
da. This proposal was selected as a candidate of the next year's
project. We had two more pre-assembly meeting and as a conclu-
sion of several key companies, Jeida Common Lisp committee was
scheduled to start in April 1985.
2. The activities of Jeida Common Lisp committee
2.1 Purposes
The purposes of the committee is NOT to make a domestic
standard lisp in Japan. The work was governed by the following:
1) Understand the Common Lisp specification
2) Discussion on implementation techniques
3) Investigations of existing CL implementations
4) Communicating with CL community of the USA
5) Investigations of applications of Common Lisp
2.2 Organizations sending members
Here is an alphabetical list of the early 28 organizations which
sent members, including several subsidiaries of USA companies.
Aoyama Gakuin University, DEC Japan, Electro-Technical Lab
(MITI), Fuji Electronic, Fuji Facom, Fuji XEROX, Fujitsu, Hita-
chi, JRC, Matsushita (panasonic), Meidensha, Mitsubishi, Nippon
Telegraph and Telephone (NTT), NEC, nippon Data General, Omron,
Oki electric, panaFacom, Sanyo, Sharp, Sinko, Sord, Sumitomo,
Symbolics Japan, Toshiba, nippon UNIVAC, Yamatake-Honeywell
(later in 1986, Kyoto university, and several companies joined)
2.3 Brief history
From May 1985, the meeting has been held once a month. In Sep-
tember 1985, a Common Lisp work shop was held for intensive dis-
cussion. Under the committee there were two groups in 1985 and 4
groups in 1986; an object oriented working group(OOWG 1985-), a
subset working group(subsetWG 1985-), a kanji working group(kanji
WG 1986-), a bboard working group (bboardWG 1986-). The summary
of OOWG, subsetWG and kanjiWG is attached as PART II contribut-
ed by the chair of each WG. At monthly meeting of Jeida Common
Lisp committee, along with the technical discussions the presen-
tation of the Common Lisp implementors, and related announcements
and discussions are there. (we had the hearings from DEC, NTT,
Hitachi, Fujitsu, Fuji Xerox, DG, Symbolics, ...)
2.4 questionnaire asking the directions
To know the basic needs, in October 1985, the Common Lisp commit-
tee sent questionnaire to selected organizations, whom might be
considered to be the most advanced in Lisp related works in
Japan. This results of the questionnaire assured the direction
of the later related activities of us in japan. We found the
needs for Common Lisp is large and if we can make a line for ob-
ject oriented facility inclusion, japanese character provision,
subsetting consideration on Common Lisp, it will almost cope with
the japan domestic needs which was considered at the time of the
questionnaire. The details are summarized by the editor elected
by the committee, which is attached in PART 2. Major differences
between the population status of '85 and that of now are KCL is
now more used and there are several Common Lisps as company pro-
ducts, such as HiLisp from Hitachi and Fujitsu Lisp. The ques-
tionnaire reflecting the current status is under consideration
but not yet performed.
2.5 working groups under Jeida Common Lisp committee
The formation of the WG is based on the results of the question-
naire. That is, subsetting, object oriented facilities, japanese
character manipulation. From time to time, the author have sent
private mails and common lisp bboard mails. The triggering of
the kanji issues, subsetting issues and other mails were there.
While we have discussions based on the communications, as Dr.
Yuasa of Kyoto university brought us a copy of the archives, we
formed a bboardWG to translate the contents.
Subset WG made a CL/Core design and reported to USA. OOWG inves-
tigated the OO bboard discussion given by Ken Kahn and later by
G.Kiczales, and use PCL as an executable model to analyze. The
versions of PCL have been brought from G.Kiczales with the cour-
tesy of Xerox PARC to the author. They were re-sent to OOWG
members, along with universities and software vendors. Kanji WG
made a design to cope with japanese characters with the major
contributions from Fuji Xerox and Symbolics along with the
japanese companies. From the author's point of view, the current
design was only to cope with japanese characters. So the author
asked them as a task of 1987 to extend it to more universal
specification to cope with the multi national treatment. Say, It
should be possible for the Chineses Common Lisp can translate
japanese natural language texts into arabic ones on the United
states machines. After the discussion is over, it will be avail-
able to anyone. (the progress is well understood anytime by
several USA companies who sending members).
3. Common Lisp implementations in japan.
The questionnaire told the most dominant Common Lisp in japan at
that time was VAXLisp, whose population was the second among the
overall Lisp population. (the number 1 is 4BSD Franzlisp)
There are KCL (kyoto Common Lisp), HiLisp (Hitachi Lisp), and
others to be appeared as japan domestic products, while Symbolics
Common Lisp, Vaxlisp, and other US made Common Lisps are also
well used. As for the Common Lisps on PC, there are several
Lisps which claim a subset of Common Lisp, including GCLisp,
ICLisp, muLisp and more. The populations of them are NOT inves-
tigated yet.
4. JIS Lisp WG
In 1986 July, JIS Lisp WG is formed as an official committee to
make a draft for JIS Lisp standard along with the international
movement. The activity of the JIS WG during 1986 has been
stressed on the design principles. French government asked the
JIS WG to be the contact point to Eulisp matters, and the JIS WG
agreed to do so. (But JIS WG will not make a joint effort to
make Eulisp.) JIS WG also knows the importance of Common Lisp.
The term for the work is until June 1989. JIS WG will try to
discuss the principle issues like, Lisp1/Lisp2, scoping, evalua-
tion of forms, special variables, terminology, layered model,
generic functions, inclusion of environments, etc. Members of
1986 are; Masayuki Ida (Aoyama Gakuin University, chair), Taiichi
Yuasa (Kyoto University), Y. Murao (Tokyo University), Fumio
Motoyoshi (Electro technical Lab), Nobuyuki Inada (Riken), Ikuo
Takeuchi (NTT), Toshiaki Kurokawa (IBM), Michiaki Yasumura (Hita-
chi Ltd.), Shuichi Nakamura (Fujitsu Ltd.), Yukiko Hashimoto
(NEC), Atsusi Nagasaka (Oki electric), Shigeru Kobayashi (Toshi-
ba), Masahiro Kuroda (Mitsubishi), Shoichi Itoh (standards divi-
sion, AIST MITI), Hiroshi Torii (Jeida) 6 persons (and 10 organi-
zations) are also in the name list of Jeida Common Lisp Committee
at the same time. The members of 1987 fiscal year will change in
some extent.
∂05-Mar-87 2158 RPG Re: I sent you 2 mails
∂05-Mar-87 1750 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET Re: I sent you 2 mails
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Mar 87 17:50:35 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa12591; 5 Mar 87 20:45 EST
Received: from utokyo-relay by RELAY.CS.NET id ab04899; 5 Mar 87 20:39 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA28556; Fri, 6 Mar 87 18:50:50+0900
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
id AA24398; Fri, 6 Mar 87 10:07:26+0900
Date: Fri, 6 Mar 87 10:07:26+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8703060107.AA24398@tansei.u-tokyo.junet>
To: MATHIS@ADA20.ISI.EDU,
a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Re: I sent you 2 mails
Cc: RPG@SAIL.STANFORD.EDU
Bob, yes, it was a report you are hoping for.
I will appreciate you will print it in the US and distribute at the meeting
with the kind assistnance of Dick.
The meeting schedule was changed from March 5 to March 4.
And we have had important meetings 4 or 5 times in Feb and March.
I was asked by the chair of the JIS standardization committee
which is the boss of my JIS Lisp WG to have more close direction to Common Lisp.
I and he made every eforts to do so. I now have a strong confidence
to steer my JIS Lisp WG.
In 1987, I will send mails as a chair of JIS WG saying japanese official comments
to assist Common Lisp based standardization efforts of US, oops,
"In 1987" means "after April 1987".
One question.
Where I can submit comments on Common Lisp Object system ?
commonloops.pa @ xerox ?
Common-lisp @ su - ai ?
X3j13@su-ai ?
I have over 20 points to suggest. The list I am maintaining was checked by
the persons from Fuji Xerox, Symbolics japan, Nippon Univac (TI-explorer),
NEC, and NTT specialists. They gave me more advices.
I dont want to discuss about my list by E-mail to avoid the chaos.
Please suggest a best way.
Thank you Bob and thank you Dick.
Sincerely yours
Masayuki
"a37078%ccut.u-tokyo.junet%utokyo-relay.csnet"@RELAY.CS.NET/su
News
Prof IDA:
I have printed up your report and will pass it out at the X3J13 meeting.
Please mail your comments about the object system to:
Common-lisp-object-system@sail.stanford.edu.
-rpg-
∂14-Mar-87 2006 RPG summary of replies to 86-019
∂14-Mar-87 1921 mike%acorn%LIVE-OAK.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU summary of replies to 86-019
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Mar 87 19:20:56 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 14 Mar 87 22:19-EST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 33170; 14 Mar 87 21:59:58-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 57861; Thu 12-Mar-87 15:07:19-EST
Date: Thu, 12 Mar 87 06:43 est
From: mike%acorn@oak.lcs.mit.edu
To: RPG@SAIL.STANFORD.EDU,
KMP@SCRC-STONY-BROOK.ARPA,
"willc%tekchips@tek.csnet"@CSNET-RELAY.ARPA,
"RSG%OZ"@AI.AI.MIT.EDU,
DLW@SCRC-STONY-BROOK.ARPA
Subject: summary of replies to 86-019
Reply-To: mike%acorn@oak.lcs.mit.edu
To: x3j13 subcommittee on Lisp1/Lisp2.
From: mike beckerle
This is a bit late for discussion at the March meeting, but since I
will be unable to attend this session I wanted to forward to you a
summary of the replies to my proposal about Functional-style
programming in Common Lisp. A hardcopy of this will be available at
the meeting. Let me know if you think a revised proposal is in order
at some point, etc.
See you at the June meeting.
...Mike Beckerle
********************************************************************
Summary of Responces to x3j13 document 86-019.
Titled: Accommodating Functional-Style Programming
in Common Lisp.
10 March '87
Mike Beckerle
Gold Hill Computers.
********************************************************************
The following people sent responces to the proposal document 86-019.
Allan C. Wechsler
Jonathan A. Rees
David A. Moon
Scott E.Fahlman
Larry Masinter
Reactions to the original proposal were mixed, with some points
drawing more controversy than others. The responses are included
below. First, for context let me briefly excerpt the 5 points of the
proposal, and provide my own summary of the comments by Wechsler,
Rees, Moon, and Fahlman. Masinter is the dissenter of the group.
Change 1:
To section 5.2. Functions
Function call forms should be changed to allow the lisp1 like
syntax of:
((f g) h)
((lambda (x) x) #'(lambda (y) y)) 10) => 10.
This change was generally favored with important clarifications by
Rees and Moon about the semantics of ((f g) h) when (f g) is
"EFUNCTUATED" (Moon's term). Rees pointed out that the semantics of
((f g) h) cannot be given in terms of (funcall (f g) h) since that
begs the question of what a symbol as the car of the list means, in
particular, the symbol FUNCALL. Moon pointed out that the
efunctuation rule must be carefully explained, so that in ((f g) h)
if (f g) returns something that is not FUNCTIONP, then one should not
recursively evaluate that list again, etc. since the scope of the
variables in that list would be unclear. My origninal intent was that
in ((f g) h) if (f g) returns anything other than a FUNCTIONP object,
then it IS an error. (I am ignoring the case of macros for the
moment. The semantics of ((f g) h) when F is a macro must be
described of course.)
Masinter thought this change would complicate the semantics of the
language, increasing the number of exceptions in the evaluation rules,
etc. I was rather surprised by this since I feel this greatly simplifies
the language, making fewer exceptions in the difference between
evaluation and efunctuation. He is definitely right that the
description of how macroexpansion is effected by this change was
not adequate in the original proposal.
Change 2: Section 7.1.1.
The FUNCTION special form will be optional in front of
lambda expressions regardless of where they appear in a
program text. (The obvious exception for within quoted lists
obviously applies here, but isn't worth mention.)
It is as if the following definition was part of the CL system
(Defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
This is the least controversial change, since this macro works in
CL now.
Change 3: Section 20.2
For syntactic convenience, the value cell of all CL symbols
which are defined as functions are defined to contain
the function object as well as the function cell.
E.g.,
(symbol-value 'mapcar) => #<compiled-function 1234>
(symbol-function 'mapcar) => #<compiled-function 1234>
This change was generally opposed. I would be willing to withdraw it.
Change 4: Section 7.11. Use of Higher-order Functions
FUNCTIONAL Vars* {form}* [Macro]
Allows syntax of:
(defun doublemap (f g)
(functional (f g)
(lambda (list) (f (g (mapcar f list)
(mapcar g list))))))
(defun y (f) ;; the paradoxical combinator
(functional (f)
((lambda (x)
(functional (x)
(f (x x))))
(lambda (x)
(functional (x)
(f (x x)))))))
This proposal was generally favored. There is a similar
proposal for &FUNCTION syntax in the lambda-list, and
also Rees points out that declarations could be used instead.
Change 5: Section 7.1.1. (again)
SYMBOL-CONTENTS symbol [Function]
Combined operation on both function and value cell.
(defun foobar (x) x)
(symbol-contents 'x) => #<unbound>
(setf (symbol-contents 'x) (lambda (x) (+ x x)))
(symbol-contents 'x) => #<function-object (lambda (x) (+ x x))>
(symbol-function 'x) => #<function-object (lambda (x) (+ x x))>
(symbol-value 'x) => #<function-object (lambda (x) (+ x x))>
(eq (symbol-function 'x) (symbol-value 'x)) => T
This change was generally opposed. I am willing to withdraw it.
At this point, I am submitting this to the subcommittee on
Lisp1/Lisp2. I will redraft (or assist in redrafting)
the proposal for reexamination if that is desired.
---------------------------------------------------------------------
Responces to ANSI x3j13 Common Lisp document 86-019
Accommodating Functional-Style Programming in Common Lisp.
Date: Thu, 15 Jan 87 18:26 EST
From: Allan C. Wechsler <acw@WAIKATO.S4CC.Symbolics.COM>
Subject: Document 86-019
To: mike%acorn@MIT-LIVE-OAK.ARPA
I'm a Lisp teacher by profession. My current feeling is that actually
changing CL to be a Lisp1 is impossible at this stage; although I prefer
Lisp1 for reasons of style, conceptual economy, and aesthetics, and
although I am nervous about CL macro semantics, on grounds of momentum
and politics I am a strong Lisp2er.
Your proposals in 86-019 show a laudable spirit of compromise. There
are a couple of technical problems -- doubtless others will point them
out too.
Change 1 -- No problems I can see. Ask Moon -- he's great at spotting
pathologies. It'll be a little harder to teach the new rules than it is
to teach the current ones.
Change 2 -- fine
Change 3 -- Problems here.
Many fine CL compilers warn programmers of scoping problems. For
example, if I try to compile
(defun foo (count)
(+ 1 ct))
I get two warnings: that there was a free reference to the variable CT,
and that the local variable COUNT was never used. This procedure
catches three common errors:
1. I misspelled a local variable name.
2. I misscoped some local-variable-creating construct (closed a LET too
soon, for example).
3. I forgot a parenthesis, as in (+ 5 CAR X).
Of course, there has to be a way to turn the warning off for known
global variable references. We use the SPECIAL declaration. If you
declare a symbol special, the compiler doesn't warn you of free
references to that symbol.
Problem: in order to disable compiler warnings about this new, enormous
class of function-valued global variables (will DEFUN create new ones?
I read you as saying "yes"), each such symbol must be declared special.
But this will give dynamic binding semantics to all those symbols! In
order to make your idea work, we must disentangle the two meanings of
SPECIAL -- turn off free reference warnings, and change binding
semantics. The obvious way to do that would be to introduce a new
declaration. So -- it's not a killer, but some people might jump on
you.
Second problem: +1, +2, and +3 are read by the CL reader as integers.
See CLtL 22.1.2, p. 339, table 22-2 "Actual Syntax of Numbers". You'll
have to come up with better names. $1, $2, $3?
Change 4 -- Clever.
Change 5 -- There is a weird sort of precedent for this in the
treatment of the "macro cell".
------------------------------------------------------------------------
Date: Thu, 15 Jan 87 23:55:35 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Document 86-019
To: mike%acorn@LIVE-OAK.LCS.MIT.EDU
cc: JAR@AI.AI.MIT.EDU, KMP@AI.AI.MIT.EDU
A few remarks, mostly nits, for you to do with as you wish. I basically
like the idea of dropping the #' off of lambda's, and allowing arbitrary
expressions in the car of a form. These changes are fully compatible.
The rest seems rather kludgey, and doesn't seem to me to be worth the
trouble.
Date: Thu, 15 Jan 87 14:31 est
From: mike%acorn at mit-live-oak.arpa
((f g) h)
((lambda (x) x) #'(lambda (y) y)) 10) => 10.
(The second example already works in CL.)
The forms above should, in every sense of the word except syntax,
be equivalent to:
(funcall (f g) h)
You don't really mean this. You don't want to go through the function
binding of the symbol FUNCALL. You have to specify that what's really
meant is function call. The meaning of a form whose car is a non-symbol
shouldn't be affected by the current function binding of the symbol
FUNCALL, as it would if the two variants were equivalent in "every sense
of the word".
Essentially, whenever symbols are used as functions, their
function-cell definitions are used. Lambda expressions and
function applications can also be used as functions.
So can arbitrary expressions, like (LET ...), (IF ...), and (PROGN ...).
Actually, you don't really mean that you can do (FUNCALL '(F G) H), do
you? The list (F G) is certainly a function application.
Your wording is the problem here. It's not right to say that the car of
a form is function; you should say instead invent a new term, like
"function expression" or "functional expression", to name this syntactic
category. ("Function" means a kind of datum and shouldn't be used when
talking about syntax.) Then say that the car of a form should be a
functional expression, and a functional expression is evaluated exactly
the same as an expression, except when it's a symbol.
The CL spec can explain the purpose of this special treatment for
function-positioned symbols in terms of the name-capture problem
of macros. Inadvertant name capture is, after all, the only real
reason for the special distinction for funtion-positioned symbols.
No! Compatibility is the main reason. Maybe you meant the only "real"
technical reason. In any case, don't use judgmental terms like "real"
in a proposal like this, it doesn't help; people will certainly
disagree.
The FUNCTION special form will be optional in front of
lambda expressions regardless of where they appear in a
program text. (The obvious exception for within quoted lists
obviously applies here, but isn't worth mention.)
This is going about it ass-backward. Better to say that LAMBDA is a new
special form, and that (function x) is just like (the function x),
except that x is a functional expression, not an expression. I.e. make
FUNCTION act just the same as the car position of a form.
For syntactic convenience, the value cell of all CL symbols
which are defined as functions are defined to contain
the function object as well as the function cell.
You should define what you mean by "CL symbols".
This is a pretty random half-way measure, when you don't specify any
change to DEFUN, and it breaks the rule that system functions and user
functions should look as much alike as possible.
I suggest that the following renamings be used:
+ => +1 ...
Conflicts with the syntax for numbers (in this case, positive one).
Suggest something else.
(defun doublemap (f g)
(functional (f g)
(lambda (list) (f (g (mapcar f list)
(mapcar g list))))))
You should consider using DECLARE for this purpose rather than inventing
a new special form. There's a precedent for DECLARE carrying semantic
import, namely SPECIAL. I'm not very serious about this, since I
consider DECLARE SPECIAL to be an abomination, but it's always goodto be
consistent with the approach taken by the rest of the language, even if
you don't agree with the approach. Consistency is the most important
thing, even if it means consistency with something you don't like.
-----
You might be interested in taking a look at my scheme-in-common-lisp
implementation, if you haven't already. It's in file "JAR; PSEUDO 102"
(doc file is "JAR; PSEUDO DOC") on MIT-MC. DEFINE becomes DEFUN plus
SETQ, SET! at top level becomes SETQ plus (SETF (SYMBOL-FUNCTION '...)
...), and there's a macro called something like ALLOW-FUNCTION-REFERENCES
whichturns into an appropriate MACROLET.
Jonathan
---------------------------------------------------------------------------
Date: Thu, 15 Jan 87 23:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Document 86-019
To: mike%acorn@MIT-LIVE-OAK.ARPA
cc: x3j13@sail.stanford.edu
Date: Thu, 15 Jan 87 14:31 est
From: mike%acorn@mit-live-oak.arpa
I don't know if X3J13 is the right mailing list for technical discussions,
but I'd like to offer a few comments on your proposal. To avoid contributing
to total mail overload, I will abbreviate your proposal as much as possible
when referring to it.
Change 1: Function call forms should be changed to allow the lisp1 like
syntax of: ((f g) h)
i.e., the "function" position of an application should be treated
specially only if it contains a SYMBOL. If it contains a list
it should be interpreted as an application itself.
I think this is a good idea. It's a kludge, of course, and creates a
small inconsistency in the language (allowing list forms but not symbol
forms), however I think the ratio of benefit to harm is favorable.
Maclisp on the pdp-10 used to have a feature similar to this, but it was
removed because it caused a lot of problems. I believe the problems can
be traced to the fact that it allowed the result of evaluating a list or
efunctuating a symbol to be another list, which was then evaluated. The
question is, in what lexical scope should that list be evaluated. Your
proposal avoids this problem by forbidding repeated evaluation.
Your proposal allows repeated efunctuation (that is, the result of
evaluating a list can be a symbol, which is then efunctuated) and you
don't specify in what lexical environment the symbol is to be
efunctuated. CLtL is not very clear on this point; p.107 says that
APPLY efunctuates in the global lexical environment if given a symbol,
but otherwise the issue is not addressed as far as I can see. This
feature may not be essential to your proposal; you might want to remove
it.
(For those who haven't seen the term before, "efunctuate" is what the
FUNCTION special form does.)
Change 2: It is as if the following definition was part of the CL system
(defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
This is definitely a good idea and causes no problems.
Change 3:
For syntactic convenience, the value cell of all CL symbols
which are defined as functions are defined to contain
the function object as well as the function cell.
I don't think this is a good idea, because it creates an artificial
distinction between built-in CL functions and functions defined by
the user with DEFUN or LABELS. If the rule of storing the definition
in both cells applies to the latter type of functions too, then
we would just have Lisp1.
Change 4:
The Functional macro is used to create an environment where the
variables in the list "Vars" can be used both as variables and
in function position within the body forms without need for the #' or
(function ...) operator, nor use of (funcall ...).
This is a good idea. To me it seems that having this eliminates the
need for your change 3.
Change 5:
Symbol-contents returns the contents of the value-cell of the
symbol when used as an accessor. When used as an assigner
(with setf); however, the value assigned is placed into both
the function-cell, and the value-cell.
This stands or falls with change 3. Again, I think change 4 is
a better approach.
----------------------------------------------------------------------------
Date: Fri, 16 Jan 1987 11:21 EST
Message-ID: <FAHLMAN.12271401438.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU, x3j13@SAIL.STANFORD.EDU
Subject: Document 86-019
In-reply-to: Msg of 15 Jan 1987 23:13-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
This discussion should probably be on the Common-Lisp mailing list, but
since I'm responding to Moon's mail to this list, I'll do it here.
I agree totally with Moon on this one -- I was just about to write a
reply with essentially the same content as his, supporting the idea
except for parts 3 and 5.
If the goal is to make functional-style programming easier without
disrupting Common Lisp too badly, I think your proposals (minus numbers
3 and 5) do the job about 90% as well as a move to Lisp1. For those
people whose goal is to merge Common Lisp with Scheme and/or Eulisp,
then only a move to Lisp1 will do. However, unless great progress is
made on the macro issue and on ways of making the conversion less
painful, I think that a move to Lisp1 is unlikely; less radical
proposals such as yours are definitely worth considering.
I like this much better than the &function idea, by the way. that
seems very confusing and irregular to me.
-- Scott
------------------------------------------------------------------------
Date: 16 Jan 87 11:24 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Document 86-019, &function, etc.
In-reply-to: various
To: x3j13@sail.stanford.edu
These proposals fail to meet what I believe is the primary goal of those
who want 1-lisp over 2-lisp, namely, to simplify and make more
consistent the programming language semantics, to reduce the number of
different kinds of references in the language.
Instead, they do the opposite. While superficially bearing some
resemblance to 1-lisp, there are more rules for evaluation rather than
fewer, the description of the language and its semantics is complex,
there are odd exceptions. (For example, in the
funcall-if-car-of-form-is-list proposal, what if the car of the form is
a macro? A macro that expands to a symbol? To a lambda?).
It does no good to pick some minor syntactic feature of 1-lisp,
implement that, and ignore the basic principle.
--------------------------------------------------------------------------
∂08-Jun-87 1226 RPG JIS LISP
∂08-Jun-87 0011 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET JIS LISP
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 8 Jun 87 00:11:46 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa21879; 8 Jun 87 3:09 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa20697; 8 Jun 87 3:02 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA14348; Mon, 8 Jun 87 15:59:47 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA13412; Mon, 8 Jun 87 15:57:13+0900
Date: Mon, 8 Jun 87 15:57:13+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706080657.AA13412@tansei.cc.u-tokyo.junet>
To: fahlman@C.CS.CMU.EDU, gls@THINK.COM,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET,
mathis@ADA20.ISI.EDU, rpg@SAIL.STANFORD.EDU
Subject: JIS LISP
Beb,
Usually, or always in the past with my best knowledge,
Japan domestic standardization start completely after
the ISO draft is appeared. I am talking about the official
process for language by japanese government.
Several professors having the relation to standardization, especially who are interested
in the international contribution, worried about this situation.
In the spring of 1986, they and I made a discussion and formed the JIS LISP
WG to contribute international standardization of Lisp.
They suggested me that the group is the first trial of them (and of me)
to go along with the very early stage of the standardization.
But, unfortunately, there were two misunderstandings,
which are not yet solved.
One is,
the members of JIS Lisp WG are respectfull and knowledgeable persons
but does not always be interested in international standardization
through co-operative approach,
and many of them have their own experience on designing and
implementing Lisp and
many time said the phrase like;
"USA 'movement' is the things of Common Lispers and JIS WG is
to talk about 'Lisp' not about 'Common Lisp'."
As the result, several of them especially Mr. Kurokawa,
strongly insisted that the JIS WG should not committ
to any other nation's domestic activity and
should make an independent design and send it to ISO.
(I feel it is a stupid idea.)
I and several of us told them that JIS is for industries
and not for the main subject of academic research to explorer new technologies.
They still wanted the table of JIS LISP WG to be
the table for thinking what is the best Lisp spec.
The second problem is related to the japanese culture.
As I stated in the top, most of the language related people think
JIS discussion should be delayed after ISO is active and ISO has a draft.
And, as Scott suggested in May 1986, japanese culture
favors the official committee work should be
carried by senior person with very slow steps.
ANSI activities seemes to fast for them to follow
though I tried to let them informed everything happened
in USA as far as I know.
And there is a communication gap among the members.
Or there is a quite difference about the information
networks.
Several members have E-mail links inside japan,
and several has E-link to USA, as you know.
But severals have no E-links to the out world
even in japan.
Some companies have a policy of isolationism, so they cannot connect their
machine to other host !
As a result, the following situation arise:
Though they have important information but it cannot
be proved by themselves and was treated as one the many information.
One of the big mainframers in japan is it.
I thought JIS WG is going to treat CL language details, I hoped,
so, I left the discussion around the language details
intentionally untouched by Jeida Common Lisp Committee (JCLC),
which is the committee of Common Lispers.
Recently, the several companies supporting JCLC implemented
their own Common Lisp, and they piled up the opinions to Common Lisp spec.,
and they have their own testing suites.
Taking account these situations,
I decided to be a p-member of ANSI X3J13 after Palo Alto meeting was over.
and sent the fee to CBEMA on April 1st or so.
The money I sent to CBEMA was later given by Jeida after their decision.
So, I represent myself but financially partly supported by
JCLC, and the fact was known by JIS WG.
I will consult with JCLC to support X3J13 as for clearn up issue
or editorial issue I can concern. I am now loading
my CLtL japanese draft of my S3620 as a base for revision up.
This is the whole story as of now.
Unless there will be no trigger from outside japan,
with my observation, JIS WG cannot make any meaningfull decision
for a while.
I cannot tell how long is 'for a while'.
It may be three months, half ayear, one year or more.
Please remember JCLC is quite healthy and I too.
Thank you
Masayuki
∂08-Jun-87 1226 RPG again
∂08-Jun-87 0051 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET again
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 8 Jun 87 00:51:15 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa22026; 8 Jun 87 3:47 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa20869; 8 Jun 87 3:42 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA14374; Mon, 8 Jun 87 16:07:29 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA13712; Mon, 8 Jun 87 16:04:54+0900
Date: Mon, 8 Jun 87 16:04:54+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706080704.AA13712@tansei.cc.u-tokyo.junet>
To: fahlman@C.CS.CMU.EDU, gls@THINK.COM,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET,
mathis@ADA20.ISI.EDU, rpg@SAIL.STANFORD.EDU
Subject: again
Dear Bob,
The first line of my last mail has typo error.
Beb, -----> Bob,
I'm sorry.
Do you have an idea to send your mail to JIS WG
to ask the official liason ?
I'm not so serious. this is only my frank talk
without deep think.
Masayuki
∂09-Jun-87 1101 RPG Common Lisp vs Lisp : terminology issue
∂09-Jun-87 0217 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Common Lisp vs Lisp : terminology issue
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 9 Jun 87 02:16:56 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa02660; 9 Jun 87 5:05 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa27940; 9 Jun 87 5:02 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA21848; Tue, 9 Jun 87 17:50:48 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA06902; Tue, 9 Jun 87 17:48:17+0900
Date: Tue, 9 Jun 87 17:48:17+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706090848.AA06902@tansei.cc.u-tokyo.junet>
To: fahlman@C.CS.CMU.EDU, gls@THINK.COM,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET,
mathis@ADA20.ISI.EDU, rpg@SAIL.STANFORD.EDU
Subject: Common Lisp vs Lisp : terminology issue
Bob,
Thank you for your coment on US delegation.
Your comment is just what I am believing.
Can I ask one question ?
When I directed to make a JIS group,
I found the name is JIS 'LISP' WG, not JIS 'Common Lisp' WG.
It might be my mistake that I did accept this name.
Or it might be a hard but good trial.
Anyhow, we have a JIS LISP WG, not JIS Common Lisp WG.
And, I've heard that Prof. McCarthy said
'there is no Lisp standard in the world.
the standard for one dialect of Lisp may be possible.'
I did not heard this kind of message directly from him.
(So, I may be wrong.)
Unfortunately, JIS group seems to try to discuss
about the Lisp standard wihich is the integration
of lots of Lisp dialects.
I think it is impossible (or its not feasible.)
Could you tell me your attitude or philosophy
on using the word 'Lisp' or 'Common Lisp' ?
Or, do you have an idea to make 'ANSI Common Lisp'
be 'ISO LISP' ?
Thank you
Masayuki...
∂09-Jun-87 1108 RPG Common Lisp vs Lisp : terminology issue
∂09-Jun-87 0754 FAHLMAN@C.CS.CMU.EDU Common Lisp vs Lisp : terminology issue
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Jun 87 07:54:37 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 9 Jun 87 10:52:02-EDT
Date: Tue, 9 Jun 1987 10:51 EDT
Message-ID: <FAHLMAN.12309133894.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Cc: gls@THINK.COM, mathis@ADA20.ISI.EDU, rpg@SAIL.STANFORD.EDU
Subject: Common Lisp vs Lisp : terminology issue
In-reply-to: Msg of Tue 9 Jun 87 17:48:17+0900 from Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet at RELAY.CS.NET>
Masayuki,
Maybe I can help to answer your question about names.
I think the philosophy of most of the people in the Common Lisp effort
is that Lisp is a growing, evolving set of language ideas. There are
many branches of the Lisp tree, some of which are experimental and some
of which are stable and ready for heavy-duty industrial use. Whenever
you standardize something, you stop or greatly slow down its evolution;
that is sometimes necessary in order to create a stable base upon which
large industrial applications can be built. I think that most of us
believe that such a stable base is needed for the growing AI industry
and for applied AI work in universities. Common Lisp can provide that
base. It was never our intention to stop the evolution of Lisp as a
whole, just to freeze one reasonably up-to-date version of Lisp so that
people could use it while the rest of us go on to explore new ideas.
There is at least one other branch of the tree already in existence --
Scheme -- and it continues to evolve.
So, while we believe that it is beneficial to standardize ONE DIALECT of
Lisp, none of us wants to standardize all of Lisp. We don't want to say
that people should not use Scheme or some future Lisp dialect; we just
want to say that if they choose to use Common Lisp, this is what they
mean by that statment. If I thought that the standardization of Common
Lisp would prevent people from working on Scheme or other more advanced
Lisp dialects, I would quit this effort at once.
What we call an eventual standard is important because government
bureaucracies tend to say, "If there is a standard for X, you must use
the standard". I don't think that all Lisp users should be forced to
use standard Common Lisp; I do think that all Common Lisp users should
adhere to the standard. By naming our effort ANSI Common Lisp, we
emphasize that there may be other Lisps around, and that someday we may
want to standardize one of them as well.
Anyway, that is why we would like to have an ANSI or ISO standard for
"Common Lisp" but not for "Lisp". I think that concerns like this were
behind John McCarthy's remarks as well. He doesn't believe that ISO or
anyone else has the right to grab the name "Lisp" and try to force it to
mean just one dialect of Lisp that happenes to exist at one moment in
time. I don't think it matters much what your committee is called,
however. A committee can study the standardization of "Lisp" and then
decide to propose a standard for Common Lisp or EuLisp or whatever, as
long as we don't get into a position where the use of other Lisp
dialects is suppressed by government decree.
I think that the view of the EuLisp group is rather different from ours.
They represent less than ten percent of the worldwide Lisp community,
but because of the country-by-country voting in ISO, they probably are a
majority in that body. If they just produced a new Lisp -- some
three-level variant of Scheme. perhaps -- it might be ignored unless it
contained some really good new ideas. Perhaps I am too cynical, but I
believe that *SOME* of the Eulisp people want to have a single
internation standard for Lisp, which they would control, in order to
force people to use their particular dialect. We have suggested many
times that there should perhaps be an ISO Common Lisp and, some years
later, an ISO Eulisp/Scheme. The former is for industrial use in the
near future, and contains many compromises; the latter would be a new,
cleaner, more rational design for the future. So far, the Europeans
have always rejected this view.
-- Scott
∂10-Jun-87 0844 RPG ISO schedule
∂10-Jun-87 0333 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET ISO schedule
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 10 Jun 87 03:33:34 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa06915; 10 Jun 87 6:30 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa05256; 10 Jun 87 6:22 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA28142; Wed, 10 Jun 87 19:18:17 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA09680; Wed, 10 Jun 87 19:15:46+0900
Date: Wed, 10 Jun 87 19:15:46+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706101015.AA09680@tansei.cc.u-tokyo.junet>
To: fahlman@C.CS.CMU.EDU, gls@THINK.COM,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET,
mathis@ADA20.ISI.EDU, rpg@SAIL.STANFORD.EDU
Subject: ISO schedule
Scott,
Thank you for sending me your comment on the naming issue.
I feel relieved. I understood your statement is quite same
as your E-mail of last year.
Bob,
Could you give me your schedule in mind for ISO Lisp ?
I mean, in japan, ISO corespondence is carried by IPSJ
and we have not full knowledge about the progress of ISO matter.
JIS Lisp WG and JCLC have no relation to ISO thing yet.
This situation may change in the (near) future.
So, we want to have arough image of the progress on ISO Lisp.
When the draft will be presented ?
There was a fllowing talk at a meeting of last year;
"if ANSI will make Common Lisp as the national standard
in 1988,and it will be send to ISO and accepted as draft
in 1990 or so, we should take more care of ISO.
Because even if we can make a draft in 1988 in japan
it will need one or more year to be approved by the parent
committee.
Or, if ISO schedule will be delayed by more than five years,
ANSI Common Lisp will have a role of the acting worldwide
standard for industrial use.
In such case, we should have more close relation to X3J13 work.
And JIS WG itself will think the ideal Lisp specification
with long term view."
-- Masayuki
∂10-Jun-87 0844 RPG appendix: ISO schedule
∂10-Jun-87 0348 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET appendix: ISO schedule
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 10 Jun 87 03:47:58 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa07092; 10 Jun 87 6:46 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa05359; 10 Jun 87 6:42 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA28203; Wed, 10 Jun 87 19:30:18 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA09906; Wed, 10 Jun 87 19:27:47+0900
Date: Wed, 10 Jun 87 19:27:47+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706101027.AA09906@tansei.cc.u-tokyo.junet>
To: fahlman@C.CS.CMU.EDU, gls@THINK.COM,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET,
mathis@ADA20.ISI.EDU, rpg@SAIL.STANFORD.EDU
Subject: appendix: ISO schedule
I feel the latter case will happen.
To my regret, I cannot attend the next meeting of X3J13.
Instead, I asked Mr. Shiota to attend .
I delegate him.
He can make a presentation on multi-byte character issue.
He have been in the center of kanji discussion and
he knows everything about what was proposed to JCLC
by each implementation.
If september meeting will be held in the week of sept.7 -12
or Sept.14-19, I can attend.
-- Masayuki
∂19-Jun-87 1543 RPG Bob Mathis?
∂19-Jun-87 1448 spar!schoen@decwrl.dec.com Bob Mathis?
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 19 Jun 87 14:48:45 PDT
Received: by decwrl.dec.com (5.54.3/4.7.34)
id AA13258; Fri, 19 Jun 87 14:48:19 PDT
Received: By spar.SPAR.CAS.SLB.COM (from gyro.SPAR.CAS.SLB.COM)
id AA22312; Fri, 19 Jun 87 13:17:58 PDT
Return-Path: <schoen@gyro>
Received: By gyro.SPAR.CAS.SLB.COM
id AA05594; Fri, 19 Jun 87 13:17:42 PDT
Date: Fri, 19 Jun 87 13:17:42 PDT
From: Eric Schoen <spar!schoen@decwrl.dec.com>
Message-Id: <8706192017.AA05594@gyro.SPAR.CAS.SLB.COM>
To: RPG@SAIL.STANFORD.EDU
In-Reply-To: Dick Gabriel's message of 19 Jun 87 1202 PDT <8706191902.AA09867@decwrl.dec.com>
Subject: Bob Mathis?
Thanks. A couple of weeks ago, he and Larry Masinter and I were discussing
scheduling of the window systems sessions (both ours and a presentation from
the X group [Schieffler, I think]) at the meeting. Bob scheduled us for
Tuesday afternoon; I asked him if it would be possible to move us to Thursday,
but I haven't gotten a reply.
I have a prior committment on Tuesday (symphony tickets--"Since when do
personal concerns enter into these things?" says Larry) I'd like not to break,
but I will if it's not convenient to reschedule the windows session.
Eric
"spar!schoen"@decwrl.dec.com/su
Schedule
Eric, the X3 meeting is currently scheduled to take place tuesday
and wednesday (June 30 and July 1). Here is the tentative schedule
sans your part. I think most people already have planned to leave
wednesday night. There is a private CLOS meeting thursday July 2,
which I intend to attend, but you could try to see whether people
might want to stay an extra day.
Tuesday morning -- clean-up committee
Tuesday afternoon -- X windows presentation, Japanese
characters presentation, administrative work of committee,
reports from various subcommittees and liaisons
Wednesday morning -- continuation of subcommittee reports
and other business, clean-up committee
Wednesday afternoon -- clean-up committee
-rpg-
∂03-Jul-87 0853 RPG Re: A multi-byte character extension proposal
∂29-Jun-87 2210 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Re: A multi-byte character extension proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Jun 87 22:09:48 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa02113; 30 Jun 87 0:04 EDT
Received: from utokyo-relay by RELAY.CS.NET id aj16893; 29 Jun 87 23:53 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA14909; Mon, 29 Jun 87 13:26:26 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA04557; Mon, 29 Jun 87 13:25:54+0900
Date: Mon, 29 Jun 87 13:25:54+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706290425.AA04557@tansei.cc.u-tokyo.junet>
To: baggins@ibm.com,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Re: A multi-byte character extension proposal
Cc: common-lisp@SAIL.STANFORD.EDU
I got a mail from nippon UNIVAC person as for the matter.
He is one of the contributors of Kanji WG.
Here is his comment.
(I am just acting as a junction between japanese net and US.)
If someone is interested in his reply, I will forward
mails to him (since direct mailing is not premitted.)
Masayuki Ida
============================ his comment =================================
Date: Fri, 26 Jun 87 16:46:31 JST
From: tshimizu@xxx.yyy.junet (Toshihiko Shimizu)
To: ida@u-tokyo.junet
Subject: Our comments to Thom Linden's q
We have reviewed the JEIDA proposal and Mr. Thom Linden's
questions. We have been making efforts for an implementation of the
extention of Common Lisp for Japanese character processing on Explorer
lisp machine. Our efforts have been made in pararell to the JEIDA
Kanji WG activity, and our specifications had been nearly fixed before
the final proposal was issued. But our implementation almost conforms
to the proposal except the point left being implementation dependent.
We think it is important to answer Linden's question according to our
implementation for your information.
First we have to give an overview of our implementation. Our primary
goal is completely the same as the JEIDA proposal that we want to use
Japanese characters "as almost the same as" characters already
available. In Explorer, an extended ASCII character set called Lisp
Machine character set has been used. We have added a new character
set for Japanese characters called JIS character set which is defined
to be the standard in Japan. This set has double-byte character code.
Explorer has the capability to handle strings whose elements are 2
byte long. This string type can be considered to be a subtype of type
string. Then we use this type of strings to hold double-byte
characters. Apparently these strings are able to hold single-byte
characters as mixture. This implementation is considered almost the
same as the scheme using "internal-thin-string" type described in the
proposal. We are now preparing a paper on this implementation for
WGSYM IPSJ, September 1987. Please refer it for further detailes.
The followings are our answers to Linden's questions;
1)
All Common Lisp standard characters are included in the standared JIS
character set, but they have different character code from the ones in
ASCII character set. This situation is almost likely in case of usual
file systems which allow JIS character set. Then we think these
difference has to be preserved when files are read into Lisp as a
sequance of characters. After that we can think of parsing, discussed
later.
2)
Above interpretation seems to lead to a contradiction against the
description in CLtL (p.233). We think that two distinct character
objects may have the same print glyphs, but in this case they shold
have the same syntactic properties. Indeed they are different
characters but somtimes we doubt. Because they may be printed using
various fonts and sometimes these printed figures are very similar.
3), 4)
Actually we have both single-byte and double-byte representations for
some characters. But we never try to map them into the one except
when the Lisp reader parses them. This is because these difference
have to be preserved as described above. And we think that once these
two representation is mapped into the one, there are no reasonable way
to make inverse mapping. This is the crucial point for applications
on Lisp to interact with other conventional applications. Suppose we
have a text processing application on Lisp and we want use it against
a text file in which single-byte and double-byte characters are
containted in mixture. It is not desirable if all single-byte
characters in the source text file are mapped into double-byte ones.
5)
Now our stand point is that a double-byte character can be a standard
character within the parsing context only if its printed glyph is
regarded as a standard character. As a result, there must be some
test for this correspondence. Acturally we have this "equivalence
test". Both the single-byte character set and the double-byte
character set include standard characters. If a character from the
single-byte character set which is a standard character, there is a
corresponding character in the double-byte character set. And these
two characters pass the "equivalence test", but they never be EQ.
However this point may lead to a contradiction to the description in
CLtL (p.20).
5a)
Then, our implementation recognizes some double-byte characters as
standard characters. For example, STANDARD-CHAR-P returns T against
#\a in the double-byte character set.
5b)
Our implementation takes option 3 in the proposal. That is, we don't
distinguish single-byte and double-byte versions of symbols, but we
preserve these difference within strings. For example, two version of
a symbol 'LAMBDA are considered to be EQ, but two versions of a string
"LAMBDA" are distinguished, or not EQUAL, but they pass the test
described above. Further, there may be mixed versions of a string
"LAMBDA".
5c)
We might agree Linden's point if we didn't think about strings.
Actually our primary understanding was that there was no need to
distinguish such a difference for the sole purpose of Common Lisp.
But there is a certain requirement for interaction with conventional
applications in which distinction between single-byte and double-byte
version is significant. Then we decided that the distinction is not
neccessary for symbols which plays an important role in programs,
whereas it is neccessary for strings which are primarily used for
interaction with outer world, such as files, displays, and networks.
5d)
As we defined that a double-byte character may be a standard
character, it is consistent to define such a character to satisfy
ALPHA-CHAR-P. Then both version of a character 'a' satisfy
ALPHA-CHAR-P, ALPHANUMERICP and LOWER-CASE-P.
5e)
We think that these description sholud be eraborated, but the JEIDA
committee has decided that these should be left implementation
dependent.
6)
In our implementation, such syntactic attributes relevant to parsing
and format controlling are only defined for standard characters. That
is, if a character is a double-byte character and also a standared
character at the same time, it may have non-constituent syntax.
Indeed it has the same syntax attribute as the single-byte version of
it. For example, a string "123" in double-byte version is also parsed
into a number 123. Otherwise its syntax cannot be other than
constituent.
7)
We think it is not neccessary to have such a large readtable which
covers all characters of type string-char. We only have a readtable
for single-byte characters and uses the "equivalent" mapping for the
double-byte version of these characters. And the rest of double-byte
characters are defined to have constituent syntax.
8)
In our implementation, MAKE-DISPATCH-MACRO-CHARACTER against a
non-standard, double-byte character is an error.
------------- end of the message -----------
∂09-Jul-87 1020 RPG Question
∂08-Jul-87 2105 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Question
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 8 Jul 87 21:05:04 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab03825; 8 Jul 87 23:53 EDT
Received: from utokyo-relay by RELAY.CS.NET id ad06963; 8 Jul 87 23:47 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA21058; Thu, 9 Jul 87 12:04:05 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA00845; Thu, 9 Jul 87 11:16:21+0900
Date: Thu, 9 Jul 87 11:16:21+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078>
Message-Id: <8707090216.AA00845@tansei.cc.u-tokyo.junet>
To: mathis@ADA20.ISI.EDU
Subject: Question
Cc: fahlman@C.CS.CMU.EDU, gls@THINK.COM, rpg@SAIL.STANFORD.EDU
Bob,
Can I ask you one question ?
When I got an invoice from CBEMA for the annual fee for the X3J13,
it is titled with 'status' field 'p'(Principal).
I payed $175.00 and sent it to X3 Secretariat.
The invoice number is No. 8701923.
I knew the diffrence bewtween principal member and observer,
and I also knew it is the national committee work in USA, not in Japan,
But I simply understood 'I am going to be a member of X3J13 as a principal
member'.
I told this fact to the Boss of JIS language committee (which is the boss
of JIS Lisp WG) when we became to be in a complex status as you know and as
we discussed.
I decided to welcome a senior professor as the chair of JIS Lisp WG,
to solve the complex status in japan,
and I thought I am to work with US and japan co-operation-ship.
I told this story at JIS WG meeting and Jeida CL committee both.
They understood and they welcomed my story.
This is what was happend in japan.
I am afraid I misunderstood your intention.
Masayuki
∂10-Jul-87 1451 RPG Re: Question
∂10-Jul-87 1448 MATHIS@ADA20.ISI.EDU Re: Question
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 10 Jul 87 14:48:14 PDT
Date: 10 Jul 1987 14:30-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: Question
From: MATHIS@ADA20.ISI.EDU
To: a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Cc: fahlman@C.CS.CMU.EDU, gls@THINK.COM
Cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU]10-Jul-87 14:30:44.MATHIS>
In-Reply-To: <8707090216.AA00845@tansei.cc.u-tokyo.junet>
Masayuki,
You are a full member of X3J13 in all respects except one. When
we are acting as the US technical advisory group on an ISO issue
only the US members count in the voting results. I sent the
information to everyone and your comments and your sharing it
with others is welcome.
Bob
∂16-Sep-87 1506 RPG ANSI Lisp standards
∂16-Sep-87 1347 Masinter.pa@Xerox.COM ANSI Lisp standards
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 87 13:47:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 SEP 87 13:43:58 PDT
Date: 16 Sep 87 13:43 PDT
From: Masinter.pa@Xerox.COM
Subject: ANSI Lisp standards
In-reply-to: Takayasu ITO
<ito%aoba.aoba.tohoku.junet@utokyo-relay.CSNET>'s message of Thu, 3 Sep
87 19:46:24 jst
To: ito%aoba.aoba.tohoku.junet%utokyo-relay.CSNet@relay.cs.net,
ito%aoba.tohoku.junet%utokyo-relay.CSNet@relay.cs.net
cc: rpg@sail.stanford.edu, mathis@ada20.isi.edu
Message-ID: <870916-134358-5886@Xerox>
I am having some trouble with the mail system -- my last reply to you
was returned.
Q: "1) What is going on at ANSI?"
A group which is part of the ANSI standard process, X3J13, meets
regularly to discuss Lisp standardization items. The next meeting is in
November. We have discussed the Common Lisp Object System, the error
system, numerous minor clean-up items, the issue of one vs two name
spaces for functions and values, and some more fundamental semantic
changes.
Most of the work happens in sub-committees. The sub-committees "meet"
using electronic mail primarily, and the X3j13 meetings are to discuss
the subcommittee's results.
You and members of your committee can be added to the network
distribution list for announcements of X3J13 activities, and reports of
ISO activities. I would also welcome some individual contributors to
the "cleanup" committee.
Q: "Is it possible to send some of my committee members to ANSI meeting
on Lisp?"
Your committee members are welcome at the X3J13 meetings. I've attached
an announcement of the next meeting.
Q: Can I get any report to explain ANSI activities on Lisp
standardization?
Perhaps Bob Mathis (who is the chairman of X3J13) has reports of
previous meetings.
Q: Would you let me the schedule of ANSI meeting if I can send someone
to it?
See attached announcement.
For 2: what is going on at ISO?
Do you know the meeting schedule on ISO-Liso? I would like to send
some of
my committee members to ISO meeting.
{I myself may attend it if the situation allow;this year I am quite
busy as
the chairman of Department at the university.}
Bob Mathis has a report of ISO activities. Bob, can you send it via
electronic mail?
- - - - - - - - - - - ANNOUNCEMENT OF X3J13 MEETING - - - - - - - - - -
- - - - - - -
To: x3j13@sail.stanford.edu
Cc: mathis@ada20.isi.edu, dcm%hpfcdcm@hplabs.HP.COM
Subject: November X3J13 meeting
From: Dave_Matthews%hpfclp@hplabs.HP.COM
Date: Wed, 16 Sep 87 12:43:19 MST
Message-Id: <1297.558816199@hpfcdcm>
Sender: dcm%hpfclp@hplabs.HP.COM
Bob Mathis requested that I delay the meeting a month so the
subcommittees
will have more time to prepare their reports. I have rescheduled the
meeting a month later, November 16-18, which seemed to be the most
desirable dates in November. Other than the date changes there are no
other changes in the arrangements.
Dave Matthews
--------------------------------------------------------------------------
X3J13 Meeting
11/16/87 - 11/18/87
Fort Collins, Colorado
The fifth meeting of X3J13 will be held Monday through Wednesday,
November
16-18 at the University Park Holiday Inn in Fort Collins, Colorado.
Monday
has been set aside for committee meetings, followed by the main meeting
on
Tuesday and Wednesday. November is the perfect time to see fall (and
sometimes winter) in Colorado. Rocky Mountain National Park is
approximately one hour from Fort Collins.
Hewlett-Packard's travel affiliate, Lifeco Travel, has negotiated
discount
airfares that you can obtain by calling:
800-521-8858 (in California)
800-722-8755 (elsewhere)
Ask to make a group reservation for X3J13. You may also make your room,
rental car, or airport limousine reservations through Lifeco at the same
time. Payment must be made by credit card. Tickets will be mailed via
registered mail. Late reservations can be express mailed at additional
cost.
A block of rooms is available at the University Park Holiday Inn at
$46.50
plus tax per night. If you don't make reservations through Lifeco
Travel,
please make your own reservations by calling (303)482-2626 and asking to
reserve a room in the "HP X3J13" block. Reservations will be held until
6
PM unless guaranteed by a major credit card. Non-smoking rooms are
available. Check-in and check-out times are 1 PM. The block of rooms
will
be dropped on 11/2/87, but you should still be able to obtain the
discounted room rate on available rooms if you specify you are attending
the the "HP X3J13" conference.
Refreshments and lunch are being arranged for Tuesday and Wednesday. I
expect these arrangements will run $50 or less per person which I will
collect at the meeting. I should be able to update this value in a few
weeks. Please note any dietary restrictions so I can make the necessary
arrangements with the catering department.
If there is sufficient interest I would like to arrange a dinner Tuesday
evening at Cuisine, Cuisine. Cuisine, Cuisine is an intimate cafe
offering
some the best and most unusual food in Northern Colorado. It is a very
small cafe which can only accommodate 60 total patrons, but they are
willing to put together a special banquet for us. To handle a group this
large in a short period of time they would like to limit the menu to 4
items. The list of possible entrees includes: Cajun roast duckling with
spice peach gravy, chicken boursin (double breast of chicken stuffed
with
herbed cream cheese dressing and mushroom voloute' sauce), shrimp diane
(sauteed jumbo shrimp in a garlic cajun sauce), sirloin tips with
mushrooms
and onions, poached salmon with a special sauce, or boned leg of lamb
stuffed with spinach and served with a dijon sauce. A vegetarian entree
will also be available. Entrees would be about 15 dollars, including
soup
or salad. Appetizers, dessert, and beverage would be ala carte.
Cuisine,
Cuisine accepts charge cards, but cash would also be welcome.
I would need to narrow this to the four items at least 2 weeks in
advance
so they could make the necessary preparations. Note if you are
interested
on the registration form and mark your first and second choice entrees.
Please note any dietary restrictions if this selection is not
sufficient.
Fort Collins is approximately a one hour drive from Denver's Stapleton
International Airport. From the airport take I-270 or I-70 west to I-25
and go north on I-25 towards Cheyenne, Wyoming. Take the first Fort
Collins exit, #265, turn left and drive 5 miles to the College Avenue
intersection. Turn right and drive 3 miles to the Prospect Road
intersection. Turn left and the Holiday Inn is just across the railroad
tracks on the south side of the road. It shouldn't be hard to see since
it
is 8 stories tall in an area with very few building over 2 stories.
Two limousine services provide shuttle service from Stapleton directly
to
the Holiday Inn. Fort Collins Express (303-482-0505) leaves Stapleton
on
the hour while the Front Range Airporter (303-221-5466) leaves Stapleton
on
the half hour. Both are located in the baggage claim area. The charge
is
$12 each way on the Express and $13 on the Airporter.
| Prospect Road ||
=========|====================== ||
HI | ||
M | ||
O | ||
U | ||
N | Drake Road North ||
T =========|====================== /\ ||
A | || ||
I |US 287/ College Avenue ||
N | ||I-25
S | ||
| Horsetooth Road ||
=========|====================== ||
| ||
| ||
| ||
| ||
| Harmony Road HP /||\
=========|=============================================||===========
| \||/ Exit
265
| ||
||
\/
Denver
Please return the following registration form by November 2 via
electronic
mail to dcm%hpfclp@hplabs.hp.com or via US Mail to:
Dave Matthews
Hewlett-Packard Company
3404 E Harmony Road
Fort Collins, Colorado 80525
(303)339-2201
Feel free to contact me if you have any questions.
__________________________________________________________________________
X3J13 NOVEMBER MEETING REGISTRATION FORM
Name: __________________________________________________
Institution: __________________________________________________
Street Address: __________________________________________________
City, State, Zip: __________________________________________________
Phone: __________________________________________________
Network Address: __________________________________________________
Dinner 11/17 (y/n): __________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions:
__________________________________________________
__________________________________________________
__________________________________________________